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in this issue Jessica Simmons 


The Bare Bones of Leadership 


Most of my late-August evenings were spent matching American gymnasts 
compete in the Summer Olympics 


The amount of flexibilh u dedication, focus, stamina — 

and pure bravery — was fascinating to me. I guess it’s the 
idea of putting oneself in harm’s way for a shot at hard- 
earned perfection, the ultimate goal being a medal not 
only for yourself, but for your team. I had previously 
wondered how this issue’s article would begin, but then 
I watched one of the gymnasts on the balance beam 
dismount with conviction, smile, wave at the crowd, 
laugh and hug her teammate who was up next, and then 
shake her head at her coach as if to say, "‘I could have 
done better.” I watched her focus, perform, and then 
respond appropriately to each of the people around her. 
It occurred to me that this is the type of balance that it 
takes to be a project leader: knowing how hard to push, 
knowing when to laugh, knowing how to motivate, and 
knowing what to do better next time. 

In this issue, ASK writers explore ways to maintain 
that balance in their field of Project Management, and 
even what happens when they don’t. From his own 
experiences, Colby Africa learned that pushing too hard 
can take a personal toll, even though his project was a 
success in the end. He looked back and asked himself, 
“At what personal cost?” 

Sometimes one of the most simple — and the most 
human way — of keeping oneself grounded is not to 
lose your sense of humor. Ray Morgan’s story about a 
test flight gone bad tells how the sound of their model 
crashing to the ground was followed by the test team's 
hysterical laughter. The story, you will see, is much 
deeper. But the message in the example? Sometimes 
for no fault of our own, things just don’t go as planned. 
One way of dealing with it is to be able to laugh at 
ourselves. Of course, a setback itself is not to be taken 
lightly, but a leader capable of lightening the moment is 
more likely to set a positive tone for the try, try again. 

Staying optimistic is important for team morale, 
specificallv when a project is dealt a huge downsizing 
blow. After his project was cut significantly, Tom Sutliff 


was able to show his team that all was not lost and to 
help them focus on the fact that they still had a job to 
do. He had to balance the new project requirements 
with the fact that his team had been committed to 
the original project and would be personally affected. 
He stood back, got a new perspective, and upheld the 
positivity needed to lead them effectively. 

Even when you keep your chin up and work to the 
best of your ability, things still go wrong. It’s human 
nature. People train for years to make it to the Olympics 
and blow their shot during one crucial second in the 
spotlight. For Martv Davis, his crucial second was 
when the contractor dropped his 3,000 pound space- 
craft. Rather than point the finger at those around him, 
Marty stood up like a true leader and acknowledged 
what he could do better if ever in this situation again. 

The other day I read a quote that said something 
about a real leader needing a “backbone, a funny bone, 
and a wishbone.” The “bones” are representative of 
the human factors of leadership: courage, conviction, 
and perseverance, a sense of humor and the abilitv to 
not take oneself too seriously, and hope, optimism, 
and a positive drive. In this issue, the writers tell 
their stories about balancing these factors — along with 
the necessary Project Management skills, training 
and experience — a leadership fundamental absolutely 
worthv of our attention. • 
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REVIEW BOARD 


JOHN BRUNSON of the Marshall Space Flight Center, Systems 
Management Office, is a member of the NASA 
Program Management Council Working Group. He 
supports the Agency's Chief Engineer Office and 
MSFC in the review/development of Agency and 
Center Program/Project Management and Systems 
Engineering policy. He led the development of 
MSFC's Project Management and Systems Engineering Handbook as 
well as in-house training modules in these areas. He served as project 
manager for three separate microgravity payloads that flew on various 
Spacelab missions. Prior to his project management experiences he 
served as the Integration and Test Team Lead for the Tethered Satellite 
System Mission. His career with NASA began in the late 1980s as a 
member of the Space Shuttle Main Engine Engineering Team. 

COLLINS works in the Spaceport Engineering & 
Technology Research Group at Kennedy Space 
Center. She has more than twenty years experience 
in aerospace spanning engineering, R&D and project 
management. She is on the Florida Institute of 
Technology Department of ChE Industrial Advisory 
Board, the National Fire Protection Association's 
Technical Committee for Halon Alternatives, and the United Nations 
Environmental Programme Halon Technical Options Committee. 

HECTOR DELGADO is Division Chief of the Independent Technical 
I 1 Authority in the Independent Technical Authority 
and Systems Management Directorate at the 
Kennedy Space Center. Previously Hector was the 
Division Chief of Process Tools and Techniques 
in the Safety, Health and Independent Assessment 
Directorate. In 1995, he served as Senior Technical 
Staff to the NASA Chief Engineer at NASA Headquarters in 
Washington, D.C. He has received many honors and awards including 
the Exceptional Service Medal, Silver Snoopy Award, and various 
achievement awards. 





DR. OWEN GADEKEN is a Professor of Engineering Management at 
the Defense Acquisition University where he has 
taught Department of Defense program and project 
managers for more than twenty years. He retired 
from the Air Force Reserve as a Colonel and senior 
reservist at the Air Force Office of Scientific Research 
where he helped manage the basic research program 
for the Air Force. He holds adjunct faculty appointments at the Federal 
Executive Institute and the Center for Creative Leadership. Owen is a 
frequent speaker at project management conferences and symposia. 




DR. MICHAEL HECHT has been with NASA since 1982 at the Jet 
Propulsion Laboratory (JPL). He is instrument 
manager and lead investigator for the MECA soil- 
analysis payload on the 2007 Phoenix mission to 
Mars, reprising a role he played on the cancelled 
2001 Mars Surveyor Lander mission. In the course 
of his JPL career, he has served in line, program, and 
project management, and has participated in research ranging from 
fundamental semiconductor physics to martian geophysics. 

JODY ZALL KUSEK coordinates results-based management at the 
Africa Region of the World Bank. She is currently 
involved in supporting the efforts of several African 
governments to move to a focus of performance- 
based management. She has spent many years in 
the area of public sector reform, serving the Vice 
President of the United States, the U.S. Secretary of 
the Interior and the U.S. Secretary of Energy in the areas of Strategic 
Planning and Performance Management. 



DONALD MARGOLIES retired from the Goddard Space Flight 
Center in January 2004. He was Project Manager 
for the Advanced Composition Explorer (ACE) 
mission, launched in 1997 and still operating 
successfully. He received the NASA Medal for 
Outstanding Leadership for his work on ACE, and 
a NASA Exceptional Service Medal for the Active 
Magnetospheric Particle Tracer Explorers (AMPTE) mi ssion. 



DR. GERALD MULENBURG is a member of the Systems Management 
Office at the NASA Ames Research Center in 
California specializing in project management. He 
has project management experience in airborne, 
spaceflight, and ground research projects with the 
Air Force, industry, and NASA. He also served as 
Executive Director of the California Math Science 
Task Force, and as Assistant Director of the Lawrence Hall of Science. 

JOAN SALUTE is the Associate Director for Projects in the Information 
Science and Technology Directorate at the Ames 
Research Center. Joan currently is on detail to NASA 
Headquarters. Joan previously was the Associate 
Director of Aerospace. She has managed many 
NASA projects including those involving flight 
testing of thermal protection materials, commercial 
technology, commercial applications of remote sensing, and remote 
sensing science projects. Joan has been at Ames for 22 years, and 
recently completed the Sloan Fellowship to attend the Stanford 
Graduate School of Business. 

HARVEY SCHABES is the Systems Management Lead in the Systems 
Management Office at NASA's Glenn Research 
Center. He is responsible for providing oversight 
for independent assessments of programs and 
projects and for defining Center strategic plans and 
policies. He is also leading the Knowledge Sharing 
activities at GRC in collaboration with APPL. He 
started his career with NASA in 1983 in Icing Research, and since 
then has served in numerous organizations in support of the Space 
Station Program. 

CHARLIE STEGEMOELLER has served as the Associate Director, 
Space and Life Sciences Directorate, Office of 
Bioastronautics at the Johnson Space Center since 
2002. The Office for Bioastronautics is responsible 
for coordinating and implementing the NASA 
Bioastronautics Strategy — the pursuit of tools, 
techniques, and policies to reduce risks, improve 
efficiencies, and return benefits to earth through the conduct of 
human space flight operations and research. He joined JSC in 1985 
and has served within the JSC Comptroller's office, the former Space 
Station Freedom Project Office, and as a key member of the NASA/ 
Mir Phase One Program. He received the NASA Exceptional Service 
Medal in 1996, and became a member of the Senior Executive 
Service in 2002. 

HUGH WOODWARD is the President of Macquarie Business Concepts, 
a consulting firm specializing in effective project 
portfolio management. Before this position, he 
had a 2 5 -year career with Procter & Gamble. He 
served as the Chairman of the Project Management 
Institute (PMI) for consecutive terms in 2000 and 
2001. He was elected to the Board of Directors in 
1996, and before being elected as the Chair, served as vice chair and 
in several other key leadership roles. 
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FROM THE DIRECTOR S DESK Di: EdilWu HofflJiail 


A Partnership with Universities 


The Center for Program/Project Management Research is intended to be a catalyst 
for engaging universities to collaborate with NASA in the important domain of 
program and project management 


Thh Center for Program/Project Management 

Research (CPMR) recently selected a first round of 
awards for research in the field of program/project 
management. CPMR is a newly established alliance 
between the NASA Academy of Program and Project 
Leadership (APPL) and Universities Space Research 
Association (USRA). The fundamental intent of this 
partnering is to initiate a formal forum for universities 
to better assist NASA in enhancing program/project 
management capability. Specific objectives start with 
establishing a relationship between NASA and the 
university community to engage in world-class research 
in the discipline of program and project management. 

This initial objective is in no small part vital to 
better understanding and overcoming the challenges 
facing NASA and Aerospace missions. In the President s 
Commission on Implementation of United States Space 
Exploration Policy Report. NASA is encouraged to 
pursue broadened relationships with universities (as 
well as other organizations) to promote more effective 
and efficient pursuit of our programmatic goals. This 
is a common-sense strategy since the US economy has 
long been fueled bv the brainpower and wealth of talent 
located at the nation’s universities. 

In the 21st century, the role of strong partner- 
ships among government, industry and universities, 
will continue to become more visible and essential for 
a successful space program. Government has the role 
of pursuing ambitious projects that are too visionary, 
costly or risky for the private sector to pursue. Industry 
is the engine through which work is completed (approx- 
imately 90 percent of NASA funding goes directly to 
industry partners.) The university sector has been a 
less-frequentlv tapped source of capability: leading 
minds are able to research, explore and study topics over 
a longer timeframe with scientific scrutiny and debate. 

In recent years I have listened to NASA leaders ask 
fundamental questions about the nature of programs 


and projects. Many of these questions can be approached 
either from a quick-answer solution, or from the perspec- 
tive of engaging and listening to what universities have 
discovered scientifically. From the latter we can then 
determine strategically, and with reflection, what best 
fits the unique demands of NASA projects. 

Partnering with universities is certainly nothing 
new to NASA. USRA itself has its genesis in a request 
bv the NASA Administrator in the 1960s to engage 
universitv minds in lunar research. However, all of 
these efforts have been in areas of natural sciences — 
astrophysics, astronomy, life, space and earth science. 
Such collaboration with universities in the field of 
program and project management has been non- 
existent. This is partly due to a bias I have witnessed 
that "we can’t learn anything from universities about 
program or project management.” This has no basis in 
reality as universities are increasingly managing NASA 
and DoD missions: University of Colorado, Boulder. 
Johns Hopkins, and Penn. State, for example. At the 
same time, universities have established world-class 
programs that develop program and project manage- 
ment expertise: Steven’s Institute, George Washington 
University, University of Maryland, and others. 

It is consistent with the call of the President’s 
Commission to seek out and form sensible partnerships 
with academia and other organizations. The intent is for 
CPMR to promote cutting-edge research, foster greater 
collaboration, disseminate information, encourage and 
develop student councils, and generally serve as a 
resource for program/project management knowledge. 
The Center will also facilitate training, workshops, and 
developmental opportunities, providing an environ- 
ment to openly pursue innovative concepts. 

For more information on CPMR, contact Deputy 
Director David Holdridge at dhold@seabrook.usra.edu, 
(301) 805-8396, or visit the CPMR website at 
http://cpmr.usra.edu/. • 
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WHEN CONDUCTING PHYSICAL SCIENCE RESEARCH IN 
SPACE, THE SMALLEST VIBRATION OR DISTURBANCE 

CAN DISRUPT SENSITIVE EXPERIMENTS. Back in the 
1990s we developed an instrument, the Space Acceleration 
Measurement System (SAMS) that flew on the shuttle to 
monitor the vibration environment — but it wasn't very flexible. 
It could only measure vibrations for three users and only at 
fixed frequency ranges, and it had to be disassembled after 
each two-week mission to be refurbished, reconfigured, and 
readied for reuse. 


Then the International Space Station came along. 

Our researchers needed a second-generation system, 
the SAMS-II, which would measure acceleration and 
vibrations for multiple payloads conducting experi- 
ments throughout the life of the station. Measurement 
requirements were all over the map with a variety 
of frequencies that needed measuring over a broad 
dynamic range, so it was essential to develop a robust 
system that would be flexible enough to accommodate 
all the particular users. 

We came up with a concept using the Space 
Stations Ethernet as the means to talk between 
multiple remote triaxial sensor systems and a remote 
controller box. Ultimately, our job was to acquire data 
within the existing constraints of the station and to 
quickly and effectively get that information to the 
scientists. In 1994 we had a $2. 1-million budget and 
a four-year development schedule aimed at achieving 
these goals. Technical risks were few and primarily 
resulted from uncertainty of ISS capabilities. At that 
point, we didn’t worry about a thing programmatically; 
our cup runneth over. 

THE GLASS IS NOW... 

Our fate, however, was tied to the fate of the Space 
Station. We were working on a system that would 
conduct experiments inside a structure that was being 
designed and built at the same time as our system. The 
Space Station began to go over budget, and they passed 


along the cost challenges to all the projects connected 
to them. By the end of a budget slashing in 1996, we 
had taken about S1.5 million in cuts. That left us with 
about $600,000 to do our job. No amount of magic 
was going to let us develop our full system — or at least 
a system that would meet the needs of all our various 
customers — for the budget we had left. 

As project manager, I had to deliver the bad news 
to the project team, but I didn’t want them to see this 
as the end. I said to them, “You know what our project 
looked like yesterday. Here is what it looks like today." 
I held up our project logo and tore it in half to hammer 
the message home. True, what we had left was smaller; 
it couldn’t meet all the original mission requirements — 
but we still had a project that was very much alive. And 
the good news: our customers still needed our sensors. 
We still had a job to do, and we needed to focus on 
what was still viable. We needed to stay excited about 
our project, even though its scope had significantly 
changed. It was going to take creativitv and enthusiasm 
to work with what we had, and I planned to make the 
most of it. “The glass is not half empty," I told them. “It 
is absolutely half full." 

Our most immediate problem was that we already 
had a signed agreement to deliver the first sensor 
subsystem to one of our customers. For now, we knew 
we couldn’t serve all of our intended users, but we 
could at least figure out a way to meet the needs of our 
initial customer. The rest would have to wait. 
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IT’S ALL ABOUT PERSPECTIVE 

The project team's response to this challenge taught 
me how resilient people and projects can be when you 
give them the chance. We took a look at our entire 
system. We said, "Okay, together we've got to come up 
with a new strategy." We already had a system design 
for the control unit and distributed sensors at multiple 
locations, but our original $2. 1-million budget was 
needed to create the control unit for the sensors. Now 
we had no money for that, and we already had the 
first sensor delivery agreement. We asked ourselves, 
"How are we going to provide the researchers with 
the acceleration data they need without our onboard 
control system?" 

As a team, we came up with a bright idea. The 
vehicle design already had laptops in the Space Station 


AN EXPERIMENT S LEGACY 

As with many small-scale projects within NASA, there is invari- 
ably a driving force behind the scenes focused on achieving the 
project’s technical and operational objectives. The Microgravity 
Acceleration Measurement System or MAMS is no exception to 
this rule; our friend Bill Wagar was that driving force behind the 
MAMS experiment. In accomplishing its important objectives of 
characterizing the sources of microgravity disturbances on the 
International Space Station, MAMS has currently accumulated 
over 1,100 days and over 25,000 hours of operation on the ISS 
since its launch on STS-100 in April 2001. 

Unfortunately, Bill passed away during the processing of the 
MAMS experiment and was unable to witness its activation and 
continued success. As a tribute to Bill and his dedication to 
MAMS, a commemorative sticker was designed and installed on 
the MAMS front panel following MAMS final processing at the 
Kennedy Space Center. Each time we are fortunate enough to 
view a video clip of the Destiny Module and catch a glimpse of the 
commemorative logo, we are reminded of Bill and how fragile life 
here on Earth can be. Increment 2 crew member Susan Helms 
summarized our feelings during a dedication offered on board the 
ISS in saying. “I myself would like to add my wishes to his family, 
my regrets that Bill has moved on to a better place, but also my 
congratulations to the work he did leave behind, because he was 
obviously extremely successful.” 



that they were using as vehicle systems controllers. 
If we used an extra one of these existing laptops as 
our onboard control unit, we could cut the cost of 
developing hardware. And since it was designed for 
flight aboard the Space Station, we didn't have to worry 
about the cost of design, development, or testing to 
meet their requirements with a new system; it would 
already be flight-qualified by the International Space 
Station program. 

There was still the issue of where to put the laptop. 
We weren't the Space Station's priority, and they weren't 
going to let us just put it anywhere. So, once again, 
the team came up with the idea of adapting one of 
the Station's existing International Sub-rack Interface 
Standard (ISIS) drawers to house the computer. The 
ISIS drawer is a standard configuration with power and 
data connections in the back. If we used a standard 
drawer, our control unit laptop would be tucked inside 
and out of the way. And since the drawer had been 
designed to the Space Station's requirements as well, 
we again wouldn't have to do any additional structural 
or thermal modeling, or worry about any other new 
payload constraints. 

Ultimately, we made an agreement with the 
program that they would authorize the project in two 
phases. The laptop control unit wouldn't give us as 
much performance as we would've had on our original 
system, but it would give us enough to support our 
initial users. We knew we had to be satisfied with a 
temporary solution or none at all, so we planned an 
eventual upgrade to the control unit with a second 
iteration of the project. In the end, this temporary 
solution allowed us to serve our initial researchers as 
well as other Space Station projects. 

AND SOME TO SPARE 

In April 2001, we successfully launched the modified 
SAMS-II aboard STS-100. After the Station crew 
unpacked their bags, configured hardware brought 
aboard, and got things going, we acquired our first 
data and down-linked it successfully. Since then, we've 
accumulated over 16,000 hours of operation. We had 
the system up and running three years ahead of when 
we would have if we'd waited for the rest of our budget 
to be reinstated. 

As it turned out, there was a point when the control 
unit laptop failed — not our custom software and not 
our unique power system. As a result of the 'built-in' 
spares on the Space Station, we were able to get another 


8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 





laptop allocated to us, put our hard drive into the 
new laptop, and get the system back up and running. 
The paperwork required to do this — and the approval 
process for it — was much harder than getting the crew 
and hardware together to make it happen. The loop 
was closed. We had provided a versatile, maintainable 
measurement system. It was supporting multiple users, 
some of whom weren’t involved in the initial require- 
ments development phase. And we did it in spite of 
technical and programmatic obstacles. 

I think that this comes back to the general attitude 
that we had about the project. As a project manager, 
you’ve got to remember to give a little bit of positive 
reinforcement along the way. Sometimes you have to 
keep reminding your team that the glass is half full, or 
at least there is enough in the glass to keep going. 

There are always going to be cracks forming — but 
if you hold it tightly, you may find you can slow those 


leaks enough to make it to the finish line before the 
glass empties. Many times, what you need to do is 
believe in the positive — and then go make it happen. 
This time we were able to find a smaller glass. That's 
what project management is all about. • 

Lessons 

• Leadership requires realism coupled with optimism. 

• Constrained resources are often the best way to 
provoke innovative solutions. 

Question 

How can you artificially create a situation in which resources 
are frequently constrained for the purpose of triggering 
such innovation? 


THOMAS SUTLIFF 


is certified as a Project Management Professional by the Project Management 
Institute. He has been employed by the NASA Glenn Research Center in Cleveland, 
Ohio since 1983. In 1999, he began managing the Microgravity Combustion Science 
Program, which is chartered within the Office of Biological and Physical Research 
(OBPR), leading the formulation and implementation of physical science research 
projects aboard the Shuttle and International Space Station. 
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About a year and a half ago. I sent all of mv 
people — the support contractors and the civil 
servants alike -to risk management training. 


It was part of an ongoing commitment to manage 
risk effectively on my weather satellite program 
at the Goddard Space Flight Center. 
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T hey broke into groups for a full day of training, 

and then they all got together for a workshop to 
create a list of the risks we faced. When I came into the 
workshop. I told them that they were free to suggest anv 
risk they wanted, but they needed to understand that 
our senior management team was going to review all 
the submissions to decide what was relevant. 

“Your imaginations could go wild." I explained to 
them, “and you could generate hundreds of risks — that 
vou get run over bv a car, or other things like that. 
We can't plan for situations like that. So don’t submit 
ridiculous things to us like, 'We re going to crush an 

£5 C> O 

instrument,’ or 'We’re going to drop the spacecraft.’ 
Those just aren’t credible.” 

At the end of the day. we collected all the risks they 
came up with, and we entered the credible ones into our 
system for tracking. We reviewed some of these risks 
every other week and revisited the entire list periodi- 
cally. We were doing what we could to manage risk on 
the program — or so we thought. 


ytnUi£- nut tjjriruj i hr he Li ev e urhat ha ppened 

On September 5, 2003, my wife and I left to go on 
vacation. We planned to spend two weeks wandering 
around New York State seeing all the sights. When we 
left the house. I turned off my cell phone, but kept my 
pager on — in case anyone needed to get hold of me. 

We had a wonderful weekend. Then, bright and 
early on Monday morning, my pager went off. It was 
the Project Manager for one of our spacecraft. She 
had been trying to reach me on my cell phone since 
Saturday to tell me that the day after I left. Lockheed- 
Martin had dropped one of my spacecraft. 

You can go through your whole career and never 
have someone drop one of your spacecraft. I think that 


would have been nice. So, one of the first things I did 
when I got back, was to inquire whether I could retire 
retroactively to Friday, so it wouldn’t have been on my 
watch. They just laughed that off. 

Then we got to work. Almost immediately, four 
investigation teams were formed — two by Lockheed- 
Martin and two by NASA. Each was tasked to inves- 
tigate a different aspect of the accident. These aspects 
included not only finding out what happened, but also 
looking for systemic problems in the program, deter- 
mining next steps, and assessing liability. 

TJUhat ureivt LrtunujJ 

The “what happened" investigation didn’t take long 
to report its findings. To begin with, the procedure 
called for eleven people to be present for this operation. 
There were only six there. The Lockheed-Martin 
people had decided some time earlier that three of them 
weren’t really needed — but thev had never redlined the 
procedure and notified us. The other three hadn’t been 
scheduled. The safety guy wasn’t even notified, even 
though he was listed in the procedure. 

The operation was scheduled to begin at 6:00 a.m. 
They also should have had a NASA QA guy there, 
but when they called him. he said he’d be in later and 
to proceed without him. When the contractor’s QA 
person arrived at about 6:30 a.m., they were on step six 
of the procedure, and he said. “Oh, you’re on the sixth 
step. Let me sign off on the first five." And he stamped 
them, without bothering to look at anything. 

One of the procedure steps involved inspecting the 
cart to make sure it was ready to take the spacecraft. 
The test conductor said he used the cart a week ago; 
so what could have happened since then? He didn’t 
inspect it. 
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Then one of the technicians went over to the cart as 
they were lowering down the spacecraft. He told them 
something looked different, but the test conductor 
didn't go over to look. He just said to go ahead. Turns 
out, there was a ring of bolts missing. That's what 
looked different. 

There were many steps 
bypassed that day, any one of 
which would have caught and 
avoided the problem. They 
ignored them all. They went 
on. They mounted the space- 
craft. Then they went to turn it 
over on their dolly, and it hit the 
ground. A 3,000-pound space- 
craft dropping three feet onto 
a concrete floor gets damaged. 

How damaged was a bit more 
complicated, but estimates ran 
up to $200 million. 

After the Mishap Investigation 
Board (MIB) draft report came 
out, the test conductor and two 
other people got fired. It was 
Lockheed-Martin's response to 
show that they wouldn't tolerate 
this kind of activity. The way I 
saw it, the people who got fired weren't necessarily the 
people who should have been blamed, because they 
weren't the root cause of the accident. I felt the blame 
really should have gone higher in the organization. The 
Project Manager was replaced six months later. 

There were several MIB conclusions with which 
I took issue. For instance, they put some of the blame 


on the government, because we didn't have our own 
QA person there at the time of the occurrence. I believe 
that I should have reviewed all of the procedures and 
to have made certain that things were in place for the 
contractor to do the work properly and safely — safely 
for the people, and safely for 
our equipment. 

They suggested that we 
needed to have a civil servant 
in residence at a plant for every 
project like this. But I don't 
think it matters what badge 
someone wears. He or she 
just needs to have the right 
dedication, the right training, 
the right experience, the right 
everything. Being civil service 
doesn't mean a damn thing. I 
have actually used civil servant 
leads and contractor leads at 
one time or another in the past. 
Either will work as long as you 
have the right person in the 
right situation. 

But I was told by my manage- 
ment, “You will implement 
everything that is in the report." 
No discussion, no exceptions. 
Around that same time, I 
got my copy of the Columbia Accident Investigation 
Board (CAIB) report. After reading it, I called my 
deputy center director. I said that the CAIB Report tells 
me not to blindly do things that I think are stupid. So, I 
said we needed to talk about the MIB report. He started 
to laugh. Then he said that he would have to think 
about that one. 



Most spacecraft are safe on their dolly: workers separate 
upper equipment module from its dolly 
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Another safe transition: 
the Apollo Spacecraft 01 7 
Command Module is 
lowered onto a dollx . 


So, we had a little standoff. Since that time, I have 
spoken with the chairman of our investigation board. I 
found out that the MIB team didn't unanimously agree 
to the things that I had problems with. The next time 
they meet in Washington, as a complete team. I'm going 
to get to talk to them. 

fl-n inrheJihlp hihU hpppa+pfl 

A risk (dropping a spacecraft) that I had summarily 
dismissed as “not credible" at our risk management 
workshop actually has real-world precedence — both 
before and after our own event. 

In mid-2000, another contractor, let's call them 
Contractor-B, dropped a spacecraft. You didn't hear 
too much about that, because it wasn't a government 
contract; it was a commercial contract. They dropped it 
because of bolts that were missing in the dolly. (Sound 
familiar?) We knew they dropped it, but the details 
never came out. 

The same Contractor-B dropped another spacecraft in 
the middle of December 2003. That made it into the Space 
News without much detail. They had just run a thermal 
vacuum test on the spacecraft in Seattle, Washington, and 
then dropped it while putting it back into the shipping 
container. Someone was hurt in that accident. 

None of these are simple cases where a team 
missed one step and so the accident happened. It's 
always a combination of skipped steps or miscommu- 
nications or dangerous assumptions. So, how do we 
mitigate this sort of risk? 

First, we need to properly identify the risk. In our 
case and the two I sited above, the real risk wasn't 
necessarily “dropping the spacecraft," even though that 
was the end result. The risk in our case would more 
accurately be called “complacency." 






We had a long-term project w r ith our contractor. 
Their attitude was that a spacecraft lift was not a risky 
thing. After years of doing this work, they saw it as 
very low-risk. But, in truth, it's always a hazardous 
operation. It should never be considered low-risk. It 
always requires the full attention they gave it the first 
time they did it. 

I've come to realize that, no matter how long 
you work in this business, new experiences will keep 
coming along. Each one broadens your horizon and 
helps you do better. • 

Lessons 

• Safety requires strict adherence to procedures. Period! 

• However, adherence to procedures in repeated operations 
also requires the careful attitude typical of “first-timers." 

Question 

To what extent is adherence to procedures — coupled with the 
right attitude f but unsupported by the proper experienced-based 
judgment — sufficient to prevent known risks , but insufficient in 
preventing the unknowns? 


MARTY DAVIS is the Program Manager 
of the Geostationary Operational 
Environmental Satellite (GOES ) at the 
NASA Goddard Space Flight Center 
(GSFC) in Greenbelt. Maryland. He 
is responsible for the design, assembly, integra- 
tion. and test of the GOES flight and ground 
support hardware and for the launch activity and 
on-orbit checkout of the spacecraft. 
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I HAD BEEN WORKING FOR TWO YEARS AS THE TECHNICAL 
PRODUCT MANAGER FOR A LARGE SOFTWARE COMPANY, 

WHEN THEIR PARTNER COMPANY GAVE ME CALL. THEY NEEDED 
GOOD SOFTWARE ENGINEERS TO CUSTOMIZE A NEW VERSION 
OF SOFTWARE, AND THEY THOUGHT I WAS THEIR GUY. 


YOU’D BETTER KNOW THE SHOT 

My former employer was a massive organization with 
tons of money. They can afford to try. try, and try 
again but even they hate to do that. At a startup, you 
typically have one shot. Screw up, and you're dead. 
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The -1 ! told me \\ hat they wanted to do to the 

software, and they even showed me some prototypes. 
Their idea was to take the basic software tool that the 
large company was producing and make it more acces- 
sible to the customer. They would do this by building 
in flexibility based on user skill level and organizational 
maturity. 1 thought that was a fascinating approach, and 
I bought into it in a big way. I decided to leave my job 
and join up with the smaller company as their director 
of software engineering. 


ISER 



MANAGING SOFTWARE HAS A LOT MORE TO 0 


We were taking a product designed for everyone and 
trying to make it work for a smaller set of users. Here 
is something I learned quickly: When you're modifying 
a commercial-off-the-shelf (COTS) product, it makes a 
huge difference if you have inside information. Why? 
Because there are undocumented features, a.k.a. bugs, 
which only people with an intimate knowledge of the 
product will know how to work around. It's something 
to think about when you're going to tailor a COTS 
product: How extensible is it from the get-go? 

We were okay because the person I had 
recommended to the company, a hotshot at my former 
company, had gone to work with them. He knew 
things about the old software that the current team 
didn't even know. But even with him on our side, we 
were bootstrapped with limited resources. We needed 
money, so we had to find a client. 

WHAT THE IDEA LOOKS LIKE 

At that point we had our working prototype. (I'm 
a firm believer that prototypes are the best way to 
communicate a vision.) We showed it to people and 
heard things like, “Oh yes, this is interesting." We had 
a few customers in mind, and we visited all of them. 
It helps to get feedback from your customers as early 
as possible (again, the prototype was invaluable). Plus, 
there's the other side of the equation, which is making 
certain that your customer has a sense (not a lot of 
detail necessarily, but a good sense) of the engineering 
constraints of your development effort. 

We found a few small clients willing to pay for 
some of the research and development we needed to 
keep going. After a while, we got enough traction to 
go after the real capital — we needed VC money. That 
was a scary proposition. We couldn't just go in and 
say, “Give me some money because I have a great idea." 
These people were very technical and very sharp. But 
we apparently said the right things, because in the end 
we got the money we needed. That took some of the 
pressure off. We now had enough money to survive on, 
but a very short period of time (about a year and a half) 
to develop a product. 


CLOSING IN ON THE DEADLINE 

This was early 1999. At that point, I was trying to hire 
the development team that would take our product 
to the next level. Because we had to get things done 
quickly, we couldn't afford to sit around thinking 
about the design for eight months before we wrote any 
code. We decided to take a milestone approach, where 
you basically pick a number of features or a quality 
bar — something — put a date on it, and run towards 
that date. 

We chose a rapid development programming 
language as the first technology to implement this 
software. We did this because the software was more 
readily modified as customer feedback came in. When 
we would show the software to the customers, they 
would say, “I think you should have this," or “Based on 
my experience it should do this..." Then we could turn 
around, go to engineering for a couple of weeks and 
send a version of the software back to the customer that 
did what they were describing. 

NO TIME TO PLAY 

That was helpful early on because we could get the 
customer's viewpoint almost immediately. It's also a 
wonderful way to force your developers to buddy up 
with the Quality Assurance guys and get things done. 
That's important because the natural instinct for 
software developers is to treat the project like a box of 
Legos. They want to take it home to see what they can 
create. You have to ask, “Okay now, is the customer 
really going to have a better experience if you put one 
more layer of lacquer on that sucker?" 

Their answer is usually, “What's a customer?" 

As a project manager, you have to be able to take 
these people who think they are just playing with 
Legos and get them to do things on schedule and on 
budget. You have to make certain they understand the 
business purpose for what they're developing. The role 
of the project manager has to be to articulate business 
requirements to the developers in a way that gets 
them jazzed — like reminding them that they're doing 
something good for the company, or whoever the target 
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customer is in the end. When it comes to managine 
software. I've found that it has a lot more to do with the 
people than it does with the processes. 

GETTING TOO CLOSE 

Our ultimate constraint was a window of opportunity, 
which was rapidly closing. Our one competitor was 
getting ready to release. We had some money, but we 
still had to do what's referred to in the industry as a 
“death march" towards our deadline. 

I was the development manager, or what is effectively 
the project manager — and I made the absolute worst 
mistake a manager can make. As development manager, 
vour job is to delegate, but I couldn’t keep my hands out 
of the coding. 

Originally, 1 didn’t think that we had the 
manpower to separate the functions of management 
and development. In hindsight, we should have. I was 
working on a number of low-level subsystems, and 
other developers couldn’t get started on their work 
until mine was flushed out. I was supposed to be 
managing these people, and here I had put myself on 
the critical path. 

It was just a crazy time. I lost 20 pounds. My team 
kept asking, “What happened to our development 
manager?” I would go into my office before it was light, 
and I would leave after it was dark. Instead of meeting 

with them to talk, I was ‘"instant messaging" my leads 
to get status reports, because I was busy cranking out 
all of this code. 

A HIGH PRICE FOR SUCCESS 

We launched in October 2001, and it was a big success. 
But I had to take a hard look at myself and ask, “At what 
personal cost?” 

I had previously thought of the developers as 
the guys who got wrapped up in creating rather than 
efficiently tailoring a product to the needs of the 
customer. Now I was faced with the truth: I had become 
one of the Lego people, obliviously adding layer after 
layer of blocks. Don't get me wrong — we software 
people do it because we love it, we have a passion for 
it. But I had let myself become overtaken by just one 
aspect of the project rather than the whole. I was losing 


weight, never seeing daylight, having virtually no 
person-to-person contact with my team... 

It was a great experience, but I wouldn’t do it again. 

I had to figure out the hard way that software itself is 
not the answer: project management is the answer. It’s 
all the people, processes, and technologies working 
together. Rather than being one of the Lego people, I 
knew I needed to figure out exactly how to motivate 
them so that together we could create products that 
make good business sense. • 

Lessons 

• When tailoring a COTS software product, you should 
recruit developers who have an in-depth understanding 
of the intricacies of the product. 

• Establishing open communication with your customer 
is not only intended to understand customer requirements 
but also to convey challenges you face on the project. 

Question 

How does an active project manager effectively delegate and 
manage without “ sticking his hands in" the actual project? 

r < 

"I wrote my first piece of software when I 
was 11." says COLBY AFRICA. ‘ When 
I was 15. I wrote my first production 
software, which was promptly rewritten 
by a 13-year-old. who went on to work 
at the media lab at MIT. The lesson j 
there is that someone is always smarter and younger 
than you are.” 

In spite of his prodigious gifts. Africa never intended to 
become a software developer. At Microsoft from 1994 
through 1999. he rose through the ranks to become a 
product manager— making time to write a little software 
on the side. Today, he works for Robbins-Gioia. a project 
management consulting firm in Washington. D.C., and is 
too busy assisting project teams around the country to 
write any software code even if he wanted to. I 

“I have a bunch of developers who work for me now.” he 
says. “Whenever I want to get my fix of software, I have 
them show me something cool they’re working on.” 
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I HAVE NOTED DURING MY CAREER THAT THERE IS A NEVER-ENDING 
AMOUNT OF RULES AND RESTRICTIONS FORCED UPON PROJECT 
MANAGERS UNDER THE GUISE OF HELPING THEM “BE SUCCESSFUL” 

IN MANAGING THEIR PROJECTS. IT APPEARS TO BE A ONE-WAY STREET; 
MANY REGULATIONS ARE ADDED, BUT FEW (IF ANY) ARE REMOVED. 
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WE NEVER SEEM TO BE ABLE TO TAKE THE 
time to clean out our project management closets and 
remove the rules and regulations we have outgrown, 
the ones that have gone out of style, and the ones we're 
not sure why we put in place to begin with. 

I had the opportunity to assist in cleaning 
out such a closet as part of a project management 
leadership team I was part of. Prior to beginning the 
process, each member of the leadership team had 
reviewed the quantity and quality of our existing 
technical standards (TSs) and standard operating 
procedures (SOPs) with the capital management 
practitioners in his or her area. The feedback we 
received from these reviews was a resounding, "We 
have too many, at times they contradict each other, and 
• we need a simpler system." Those were just the positive 
points of our system. 

Since we were in the process of "streamlining" the 
capital management TSs and SOPs used to define and 
execute our capital projects, we had an opportunity to 


took an initial cut, and reduced the TSs from 11 to 7 
and SOPs from 24 to 7. People were feeling fairly good 
about this reduction effort, but many of us questioned 
why we couldn't reduce more. As project managers 
described their role in simplistic terms, we always 
came down to the fact that they were accountable for 
managing cost, schedule, and technical correctness. 
And it worked; now we had just three main topics!!! 
We told the team reviewing the standards to be 
merciless with their reduction efforts, leaving only the 
core requirements and keeping in mind these three 
areas. The team came back with a proposal reducing 
the number of TSs and SOPs to just four each: 

1) Cost Estimating 

2) Project Execution Planning 

3) Engineering, Procurement, and Construction 
Planning 

4) Legal and Corporate Requirements 

As our leadership team reviewed this proposed 
change, they realized how much "stuff" had been 

' 
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completely rethink each one. At first we felt that we 
had done a pretty good job: We'd reduced the number 
of TSs from 18 to 11, and SOPs from 32 to 24. But 
as we reviewed our new TSs and SOPs, we noted our 
"closet" was still full. We had simply rearranged all 
the clothes by reformatting or renaming the standards 
versus actually taking something off the plate. In some 
cases, we actually changed the font size so it only 
appeared that there were less! 

Like the closet that accumulates all the stuff we 
buy and never get rid of (and just end up moving 
around) we felt our list of TSs and SOPs needed a 
major cleaning. We went back to the drawing board, 
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added to the TSs and SOPs over the years. These 
additional TSs and SOPs didn't add any actual value 
and went a long way toward explaining why the project 
management community was feeling so overburdened. 
In the beginning we expected our original 11-standard 
proposal would leave the practitioners feeling that 
we'd really helped them and streamlined the process. 
However, all we'd actually done was rearrange the 
existing data in their closet, making things harder to 
find. With our four TSs and SOPs, we felt we had left 
just the right amount of clothes in the closet. 

We decided to deploy the four TSs and SOPs, 
figuring if our project managers experienced problems, 


we could recreate what we had removed. In our 
opinion, the risk of negatively impacting our projects 
was small. We were excited to find out the project 
management community was delighted with these 
reductions and felt empowered by them. It gave them 
more flexibility to manage their projects and develop 
their own personal management style. 

Still basking in the glow of this successful 
reduction, our leadership team decided to tackle our 
capability assessment tools — another closet to clean 
out! We asked for two volunteers to review and propose 
reductions. Each one of these tools had 16 sections and 
anywhere from eight to 16 components in each section. 
Within two months the individuals returned with their 
proposal and beamed that they had combined the 
tools (GREAT), reduced the total number of sections 
from 32 to 16 (not great, but OK), and each section 
now had 15-30 subcomponents (UGH). Thus, the 
closet was still full but had been rearranged. We forgot 
how to clean out the closet again. The team rejected 
their proposal! I volunteered to try and streamline 
these tools by reapplying the process we'd used with 
the TSs and SOPs. In the end we agreed on one tool, 
four sections, and 6-10 sub-points in each section. 
The closet was cleaned out! 

After six years, the four standards and SOPs and 



Lessons 

• The natural tendency in organizations is to add new 
standard project procedures and guidelines throughout 
the years, without deleting old ones. 

• It is management's responsibility to periodically 
review and edit standard project procedures and guide- 
lines, leaving only the minimum core requirements. 

Question 

How can you encourage , in today's dynamic environment , 
appropriate flexibility necessary for implementing standard 
operating procedures? 


the capability tool have stood the test of time, and our 
project management success measures have improved. 
The streamlining process enabled us to: 

1) Reduce the effort, costs and time required to 
maintain these standards and SOPs. 

2) Focus the project managers on what is truly 
important, and allow them the creativity to 
develop their own style. 

It is management's responsibility to understand, 
review, and periodically edit the requirements it places 
on its project managers as criteria and times change. 
This is especially true since in the past we tended to 
add requirements that may or may not have added 
value. Thus, we were just building an extra closet to 
house our new stuff, versus cleaning out the original 
one to solve the problem. 

Management needs to listen to its practitioners 
to determine how they can help the system. 
Statements like “do more with less" are interesting, 
but management needs to be accountable to determine 
what rules and regulations are truly necessary 
for project managers to be successful and deliver 
successful projects. • 



W. SCOTT CAMERON IS THE GLOBAL PROCESS 
OWNER OF PROJECT MANAGEMENT FOR THE 
PROCTER AND GAMBLE COMPANY IN CINCINNATI. 
OHIO. HE HAS BOTH MANAGED CAPITAL 
PROJECTS AND PROGRAMS. AND DEVELOPED 
OTHER CAPITAL MANAGEMENT PRACTITIONERS 
WITHIN THE COMPANY'S VARIOUS BUSINESSES 
FOR MORE THAN TWENTY YEARS. 
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The . 


By Scott Tibbitts 


It was fourteen years ago, and 1 remember 
it well. It seemed that the right hand didn't 
know what the left was doing. It was crazy. 
Starsys was only eight people, and deadlines 
were being missed because someone didn't 

know what someone else needed. How could 

'■ 

a handful of people be this disconnected? 
Maybe a daily meeting would help. 
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Little did I know that we were initiating a process 
that would last for two decades. The idea was simple: 
a short, all-hands meeting once a day to maintain the 
week's actions item list. Not too tough a challenge with 
eight folks, but quite a challenge as we grew to a 140- 
person company. 


NOTE TO SELF: 1992 

Things that DO NOT work for getting a meeting 
to start crisply at 8:00 a.m.: 

1. A heartfelt plea that timeliness is next 
to godliness 

2. $l-per-minute penalties for latecomers 

3. Playing the theme from 2001: A Space Odyssey 
with the expectation that everyone is in the 
meeting room by the end of the music 

Things that DO work: 

1. A company- wide bell that rings prior to 
the meeting and lasts exactly 60 seconds 

2. A “quarter-to-the-party-fund” penalty 
for those who aren't in the room by the 
time the bell ends 



CHAIRMAN OF THE "BOARD” 

The meeting developed its horsepower during the 
first year when we started using it to publicly declare 
program actions for upcoming days. A whiteboard was 
placed in the front of the room, and each program had 
its own area on it. Actions were written, along with the 


were completed and which were moved out. The pulse 
of the company was there to see. As everyone became 
aware of each other's activities, the cross-strapping 
necessary for a high performance team just happened. 
It wasn't uncommon to hear something like, "Tom... 
I've worked with that potting material before and had 
some problems. Let's talk." 

READING THE MINUTES 

But we found out that starting on time was only half the 
battle. How could we limit the meeting to only fifteen 
minutes? A second bell was added that rang at the end 
of the meeting for 60 seconds. Suddenly the meeting 
leader was managing the meeting to finish before the 
bell. Group pressure for the meeting leader to perform 
in the time given was a powerful motivator: the board 
managers, driven by the bell, became masters of 
efficiency. We found that we could tag in on more than 
50 actions in less than 10 minutes. 

BUT CAN WE KEEP OUR PROMISES? 

The board provided a way to measure the day-to-day 
agreements made between coworkers, "Anne, I'll get 
that to you by Friday." These were now tracked giving 
us a window into the "agreement integrity" of the 
company. We started tracking these agreements and 
posting the track record for all to see; what percent of 
the informal day-to-day agreements that were made 
between people were kept? 



responsible party and the committed date of delivery. 
Anything could go up on the board — major 
or minor — as long as it had a date. Humor 
was encouraged. Peer pressure provided the 
impetus for folks to get their actions on 
the board; not doing so was to imply 
that work was not being done. 

We cycled through everyone in 
the company, each having the oppor- 
tunity to run the board for a week. The 
clear message was that the board was by and for 
the team. Each day a tally was made of what tasks 


Year after year the number hovered around 50 percent, 
and that just seemed low. We knew that if the number was 
too high, the company would be losing its nimbleness. But 
only 50 percent? We knew we could do better than that. 


NOTE TO SELF: 1995 

Things that DO NOT work for raising the 
"agreement integrity" of the company: 

1. Heartfelt pleas that keeping agreements 
is next to godliness 

2. Everyone in the room making a loud buzzer 
sound every time an agreement is missed 

3. Daily tracking of agreements and results with 
a dear goal posted on the graph, and a daily 
focus on how 7 we are “missing the mark" 


We tried everything we could think of to bring this 
number up. Nothing worked. Was this a physical law 
of organizational behavior, akin to the speed of light, 
which would never be bettered? We were not yet ready 
to throw in the towel. We had to get out of the box. 
Way out. 

MASSAGING THE PROBLEM 

I stood up in front of the meeting one morning. "Ok... 
here's the deal. If this company can exceed 75 percent 
on the board and hold it for two weeks, we will bring 
in two masseuses on Friday. We will set them up in a 
conference room, and everyone in the company will get 
a massage. Thereafter, every two weeks that we are above 
75 percent, we will do the same thing." Much discussion 
followed — mostly the “are-you-serious?" kind. 

It took 24 hours. The next day the company went 
from 50 to 77 percent. Folks were on the edge of their 
chairs as we worked the board each day, and at the 
end of the two weeks the metric was solidly above 
”5 percent. We looked for sandbagging, but it wasn't 
there. The quality of the actions had not changed. The 
company was keeping its agreements. 

Good to our word, we set up the two masseuses, 
and everyone had a 10-minute slot. 

Was it disruptive to our schedule? To some extent. 
Was it expensive? Yes... both the cost of the masseuses, 
and the lost time added up. Was it worth it? Absolutely. 
The value in increased efficiency more than paid 
the bill. It also provided a morale boost by providing 
an honoring benefit: “You are working hard, here’s 
your reward." 


1 he massages continued with the company making 
the mark about three of four times. After the first 
year the newness wore off, and the motivational effect 
lessened. After a year and a half it was time for a change, 
and the massages ended. But the 75 percent agreement 
result was there to stay. A cultural shift had happened — 
and a new habit was created — that lasted for years. 


THE PRACTICE EVOLVES 


Over the years the morning meeting has become a 
primary generator of companv culture. Through it new 
traditions have been born, legendary discussions have 
been held and critical values debated. As with many 
worthy things, over the years it too has changed. In its 
current form in a 140-person Starsys, it is a twice-a-week 
meeting. We no longer track the actions; that became 
impractical at about 75 people. In its place, once a 
week, each company department makes a 10-minute 
presentation on any topic they choose. To keep these 
worthwhile, a show-of-hands vote is taken immediately 
afterwards; was that a great use of time, a good use 
of time, or a poor use of time? The highest scoring 
department every quarter gets to take their department 
out to dinner. 

The one thing that has not changed through the 
years is the practice of “help sessions.” These were 
suggested by an employee almost 12 years ago. At 
the end of the morning meeting, team members can 
request the help of anyone else there and can meet with 
them for a couple of minutes. With everyone in one 
place at one time, it is a great way to make unscheduled 
links that help keep a team communicating. For those 
five minutes, the room is filled with small standing ad- 
hoc meetings that kick off the day. 

The question that is constantly raised, both from 
within the company and from outside, is: “Is it worth 
it?” You can do some simple math and scare yourself 
with the cost of those meetings. But at the end of the 
day, it's like the ad says, “The value of getting everybody 
together in one room at one time, twice a week, 
to collaborate on how to better accomplish our 
goals — priceless!” • 



As president of Starsys Research in 
Boulder, Colorado, SCOTT TiBBITTS 
has overseen the production of more 
than 2,000 mechanisms flown on more 
than 200 spacecraft. His other ASK 
features appeared in Issue 16 and 18. 
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TO THE TEST 
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BY RAY MORGAN 

rI IS NO MUSIC IN THE REST. BUT THERE IS MUSIC IN THE MAKING.” 


Johnny Albea. Director. Turrentme Junior High School Band. ca. 1960 
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The Quetzaicoathis Xorthrojn m flight. 
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The yaw model just before launching . 




The grounded yave model 


The largest of all flying pterodactyls, the Quetzaicoatius 
Northrop!, had no tail. Its iarge beak and head at the 
end of a long neck, made flying it equivalent to shooting 
an arrow backwards with its feathers in front. A major 
problem requiring solution before designing and building 
the final version, was to determine if we could overcome 
this instability with an automatic system. The system used 
natural features of the real animal, but with electronic 
sensors and electrical servos. 


It was late in the day, in the summer of 1985. Twilight 
had come, the sun was down and the sky was getting 
darker, making colors hard to distinguish. Lights 
were coming on around us — beyond the two-lane 
highways that formed the boundaries of the mile- 
square abandoned farming field. 

Following a series of delays and last-minute fixes 
and changes, I felt compelled to make the first tail-less 
flight of our "yaw model* 7 for the pterodactyl today. 
Over and over, we had managed to keep its nose into 
the wind by strapping it to a swivel chair base on the 
roof of my van. We had repeatedly launched the bird 
with a "launch trolley 77 fitted with a standard tail and 
wheels. All that was left for this phase of the project 
was to prove that we could launch the full-sized bird, 
release the trolley cleanly, and have it automatically 
stabilize itself in flight with no tail. 

Conditions were not very good — it was getting 
difficult to see details of the faked-out, radio-controlled 
bird even from just 50 feet away, and we were all tired 
from working late the previous night and through the 
day. We urgently needed to prove that the autopilot 
could wiggle the head, fingers, and wing ailerons fast 
enough to stabilize the bird. Otherwise, we would not 
be able to build the complete version in time to make 
the filming dates for the Smithsonian 7 s IMAX movie. 
On the Wing. 

"What could go wrong? 77 I asked myself, but 
thinking on my feet at this point was too difficult. 
Feeling too much pressure, too tired, and too hopeful 


it would work, I stepped on the foot switch that started 
the towline winch. The crude, half-scale replica of 
the 36-foot flying reptile rapidly accelerated toward a 
return pulley staked down a quarter of a mile away. 
I kept my left index finger touching the emergency 
parachute release, which was designed to allow the 45- 
pound robotic dinosaur to float down with (hopefully) 
minor damage. "The big guy would have gone for it, 
too, 77 1 told myself. 1 

My doubts began to grow as the model's form began 
to blend into the darkening landscape, and bounce down 
the dirt road toward the setting sun. I pulled back on the 
stick (by faith more than vision) and the bird rotated and 
began its rapid ascent upward, finally appearing in profile 
as it shot above the horizon in the distance. The backlit 
darkness distorted my judgment of its distance and 
altitude, so I listened as the electric winch seemed to slow 
down. I commanded a hard left bank to turn the model 
away from the towline, effecting its automatic release. 
Half way through the turn, I switched on the autopilot. 
The large head turned side to side and simulated "fingers 77 
wiggled on the outer wings. 

Seeing that the bird began to roll to wings level with 
the autopilot on, I knew it should be safe to release the 
stabilizing trolley and tail. I aimed the model back past 
our vantage point as it glided down from its release point. 


1 My boss, and the founder cf our company, had sold die idea of a flying replica of die largest 
flying animal ever that ever lived to the Smithsonian and to its primary sponsor, Johnson Wax, 
He had mode the task sound easy, with the famous words “If nature did it 65 million years ago, 
it should he easy to replicate today." 
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600 feet above the ground. We commanded the release 
of the stabilizing trolley, hoping to see the bird model fly 
straight on its own. But it didn't quite work as planned. 

Instead of simply falling away from the bottom of 
the pterodactyl's belly, the tailboom dropped down and 
to one side slightly, but remained attached (loosely) to 
the yaw model. 

I had a quick choice to make. I could immedi- 
ately deploy the recovery chute, or I could try to shake 
the trolley loose by commanding control hard-overs. 
Deploying the chute could stop forward flight and 
reduce the fall rate, or it could tangle in the trolley and 
cause the whole mess to crash down together. I decided 
to try to shake it loose. 2 

I had to be careful because the bird, at best, was 
expected to be conditionally stable without the tail. This 
meant that small perturbations from straight and level 
flight could be handled by the autopilot, but very large 
ones would cause the bird to "swap ends" in a real hurry. 
Gradually I applied more and more violent control 
inputs, trying to shake off the reluctant trolley. 

At last, the trolley and tail assembly fell free. 
Unfortunately, the bird was also approaching the edge 
of the field. I had been so focused on the trolley, and the 
motions of the model, I hadn't kept an awareness of how 
far it had flown away in the dark sky. Worse yet, the yaw 
model was tumbling out of control, and it appeared to 
be falling towards the two-lane road between the field 
and the horse stables. I quickly scanned for car lights, 
but didn't see any ...small relief. 

Suddenly, the bird rebounded back up from about 
40 feet above the ground. It had hit some high- 
tension w ires running along the roadway. At this point, 
everything seemed to take place in slow' motion. It 
cartwheeled back away from the roadway, and toward 
the field ... a big relief. 

I was waiting for some type of electrical event, but it 
seemed at first we had been very lucky. Then I noticed 
a wave moving through the wires toward me, and then 
reflecting back from a pole and propagating toward 
where the bird struck. 

KABOOMI! There was the brightest flash that I 
have ever seen in real life. An arc between the wires 
made a large ball of an intense white — almost a 
miniature sun. It reminded me of movies I had seen 
of the first atomic test at Alamogordo. Then 1 heard 


2 The bird's chute was designed to be deployed when free of die trolley; the trolley itself had its 
own chute that automatically would open once it left die bird. 


WHY YAW? 

When an airplane turns left or right, it is said 
to "yaw." The yaw axis can be envisioned as 
a vertical string suspending the aircraft about 
its center of mass. For the pterodactyl, the 
shape of its large head made it develop strong 
aerodynamic forces about this axis. With the 
head being so far in front of the center of 
mass, and with no vertical tail to counteract 
the forces it could develop, it made the replica 
want to turn and face backwards. To solve this 
problem, we had to make the head part of the 
active control system. In fact, we found we 
also had to use the "fingers" out on the wings 
(as spoilers), and use warping of the wings 
to assist the head. The latter two devices 
increased drag near the wing tips to help the 
head keep pointing into the wind. 


a sharp, short, electrical buzzing noise behind me. 
Immediately, the entire neighborhood... houses, street- 
lights, and the horse arena beyond the road . . . went 
dark, as wires fell from a transformer to the ground. 

There was a sizable crowd out to see this first flight 
attempt — families and friends of my employees, mainly. 
When the bird first fell out of control, there were 
screams. When the bright flash went off with a large 
boom, there was a collective, "Uh-Oh!" After the bird 
had settled to the field and everyone recognized there 
were no serious consequences other than blacking out 
a large fraction of the small town of Moorpark, CA, 
hysterical laughter set in. I, however, was not laughing. 
One of the flight team members (a natural comedian), 
yelled, "Well . . . I'll see you guys later." 
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I had made some serious errors in judgment, 
and I was kicking myself mentally, while at the same 
time steeling myself for dealing with the repercus- 
sions. The first thing I needed to do was to call 
the power company and get someone out to repair 
the downed line. The second thing, which I was 
dreading the most, was to speak to the owner of the 
horse arena, who was obviously going to lose some 
income for the evening. I was just finishing a call 
to the power company on a mobile phone, when I 
saw the stable owner crossing the road, looking for 
someone to blame. 

Surprisingly, when I explained what had happened, 
apologized, and offered restitution, everyone was quite 
reasonable. The power company guys thought it was 
funny (total repair bill only about $600) and when the 
stable owner found out what it was we were testing, he 
even refused compensation. 

We had taken pride in the fact that, as a company, 
we were quick to put prototypes in the air when devel- 
oping innovative aircraft, and could rapidly learn what 
the real problems were to make changes faster than 
most aerospace companies could develop analytical 
models. And, to a large degree, there is much merit 
in testing unique designs in flight as soon as possible, 
particularly with sub-scale models. I still support that. 

However, like in all of life, there is a balance. Here, 
we found that we had gone too far to the side of “hurrv 


up and get something in the air," and it actually cost 
time and money, rather than saving it. Whats more, we 
had been extremely lucky that no one was injured, or 
even killed. The model was not that big at 45 pounds, 
but it certainly could have done serious damage when 
falling hundreds of feet. We were very lucky not to have 
hit a car driving down the road, or someone walking on 
the ground. The power lines could have hit and even 
electrocuted someone when they fell. 

In hindsight (there was a lot of discussion among 
the team) we recognized that we (me, mainly) were 
just too impatient to get into the air, particularly with 
a potentially lethal flight vehicle. Because of this and 
other similar experiences, we ended up with what I 
consider a very good rule: no work on the aircraft the 
day before a planned flight test. By bringing patience 
into the flight test program, it gave us a chance to re- 
think what we were doing, and look for stupid plans or 
actions before we went to the field. 

To sum it up, it is good to rapidly put prototypes 
into the air and learn the real problems. Irv Culver, 
famed engineer of the old Lockheed Skunk Works, 
w T as a champion of this approach. That said, there is a 
time for patience in the test w T orld to allow one to think 
everything through, to create a plan for predictable 
events, and to make sure nothing obvious has been 
overlooked. Finding that balance is critical to being a 
good project manager. • 



RAY MORGAN IS HEAD OF MORGAN AIRCRAFT 
AND CONSULTING AND A SENIOR TECHNICAL 
ADVISOR TO NASA. MORGAN OVERSAW THE 
DEVELOPMENT OF MORE THAN 35 UNMANNED 
AERIAL VEHICLES (UAVS), INCLUDING NASA'S 
HELIOS AND PATHFINDER AIRCRAFT, DURING HIS TENURE AT 
AEROVIRONMENT. INC. HIS OTHER ASK FEATURES APPEARED IN 
ISSUE 16 AND ISSUE 18. 


Epilogue: The Quetzalcoatlus Northropi full-flying replica , with wing 
flapping, automatic stabilization — and nearly life-like appearance matching 
the paleontologists precise specification — made its first successful flight on 
January 7. 1986 , one week before filming was begun in Death Valiev , 
CA. Twenty-two successful flights were made for the movie , for which it 
became the main star. The movie. On the Wing, produced by Francis 
Thompson and directed by Bailey Silleck , was shown at IM AX theaters at 
the Smithsonian Air and Space Museum and around the country. 
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''"Vcror at 

ace Flight 

er ^e/np r 


Aura is an earth 


observing satellite 




developed to help us study 

the quality of the air we breathe. It will look at the 
state of the ozone and the atmospheric composition in 
regards to the Earth’s changing climate. 

I headed to California on July 5, 2004. The plan 
was that the satellite would launch on the tenth, but 
we had a few problems getting it off. This was the 
fifty-ninth launch of my career, and it was also a little 
different than most of my previous launches. Most of 
the time it's weather that postpones a launch; there 
aren't usually that many technical issues this late in the 
game. This time, however, we had several problems, 
equally split between the launch vehicle and the space- 
craft. I remember a member of the crew asking me, “Is 
this normal?" And in my experience, it wasn't. 


A WRENCH IN THE WORKS 

We had three significant spacecraft issues during 
the launch campaign. These problems, together with 
the launch vehicle problems, ended up postponing 
the launch five days. During that time, the mission 
management team met 11 times at all hours of the day 
and night to try to sort things out. I myself held four 
special reviews. 


ASK 20 FOR PRACTITIONERS BY PRACTiTIGNERS 31 



The first problem was that some tools had been 
misplaced during final spacecraft closeout, which could 
present a problem if they were left on the spacecraft 
during launch. A wrench was lost and then found. 
Then we realized that we had also lost a flashlight. 

The first step to solving this problem was inter- 
viewing everyone who had been involved with getting the 
spacecraft ready for launch. This was a massive effort, 
even extending to people overseas. Then we were able 
to make a timeline of activity based on photographic 
evidence, which were time-tagged and fairly easy to 
review. Through these measures, we were able to limit 
the possibility of the flashlight's whereabouts to an area 
that made up about 10 percent of the spacecraft. 

The likely story 

We were able to determine that the flashlight had last 
been seen on a processing table. Something called 
"scrim," which is a plastic covering that is taken off the 
fairing during its installation on the launch vehicle, had 
been put on the table. The flashlight was also on the 
table, and it was probably swept off with the trash. We 
even checked the dump, but the search was futile. 

Based on all the evidence and interviews, we were 
able to put together a story that convinced us that the 
flashlight was not on the spacecraft. What was really 
frustrating, however, is that all of this investigation 
could have been avoided. I found out that there was 
someone along the way who had noticed immediately 
that the flashlight had been misplaced. It was a week 
before they finally came forward, and by that time, the 
trail was cold. The person didn't speak up, because 
he was initially afraid to report it. I realized that 
there needs to be a clear message sent on this type of 
thing: No one is going to get in trouble for calling our 
attention to potential problems. It's the kind of behavior 
that we need to encourage. 

Shake, but no rattle 

The second problem had to do with a transistor failure 
in another program. A nickel-plated transistor can had 
been improperly cleaned, and this created the possi- 
bility of particles being generated inside the can. As 


long as they were smaller than about two thousandths 
of an inch, we wouldn't have a problem. But particles 
were reported to be larger than that. 

The screening technique for this type of problem is 
to vibrate the transistor and listen for particles rattling 
around. This process is able to detect particles down to 
one thousandth of an inch. But the parts reported as 
having particles larger than two thousandths of an inch 
had passed this test. One of the team members said that 
the noise should sound like "an acorn in a coffee cup" if 
it were that large, but there was no noise. 



Aura satellite — artist's concept. 


I asked to push back the launch date in order to 
figure out the problem. It wasn't a popular decision, 
but I felt it was a necessary one. I was able to facilitate 
a discussion between our parts and materials engineers 
and those from the program that had the problem. It 
turns out that there had been a miscommunication. 
The "particles" were actually very quiet flakes. That's 
why all the parts passed testing based on an acoustic 
response — the flakes didn't make much noise. 

We then did a thorough risk assessment for every 
application of this part in both the spacecraft and the 
instruments. Thanks to redundancy, we convinced 
ourselves we were OK. Had we just gone ahead with the 
launch, it would have been successful. But we wouldn't 
have known why it was successful. I felt we needed to 
take the extra time to figure it out. 

The minority report 

The last problem occurred during the countdown when 
there was a bit flip in the solid state recorder. We had seen 
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this occur occasionally on Aura’s sister spacecraft. Aqua, 
and it wasn’t mission-threatening. But then it happened 
again one hour from launch. I asked for a summary of 
the situation, and I was basically told that the spacecraft 
was ready to fly "as is.” I asked if there was anyone that 
disagreed with that, and I was told reluctantly that there 
was one person. His name was Michael. 

1 got Michael on the net and asked him to explain 
his opinion about the problem and his reservations. 
It turned out that he had seen the problem in the test 
program, but no one was worried because it hadn’t set 
off any alarms. While he was explaining, there were 
other people on the net that kept saying we needed to go 
ahead with the launch. As the conversation progressed, 
I could feel him getting pressure from the rest of the 
team and begin to change his mind. I again made the 
unpopular decision to delay the launch until the issue 
could be ironed out. 

So after speaking to Michael, I went to find out 
more about the problem, and to talk to mv team about 
possible solutions. Since the problem was on both the 
A and B sides of the recorder, and in the same word and 
memory section on each side, we determined that if this 
became a frequently recurring problem, we would be 
able to bypass that section of memory and work around 
it. It sounded like a viable option. 

But since Michael was the only one who had been 
concerned about the problem, I wanted to consult 
with him before moving forward. He was working 
the second shift and was asleep. I got him out of bed 
to hear the solution and to see what he thought of it. 
He believed that it was airtight. I really felt like this 
situation was very similar to what had been outlined in 
the CAIB report: When minority opinion isn’t valued, 
people are afraid to speak up, and they end up giving 
in to conformance pressure even though they know 
there’s a problem. So I wanted to make sure that I took 
the time to hear the dissenting opinion. 


motto I’ve adopted from the wine industry, and I take 
it with me to each launch. That motto is "No launch 
before its time." It’s the job of the management not to 
get caught up in the "launch fever” that accompanies 
the last few hours before liftoff. If there is an issue, no 
matter how small, it needs to be brought to the table 
and dealt with. The problem needs to be investigated, 
the risk needs to be evaluated, and sometimes the best 
decision is to postpone. Better to hold off five days — or if 
necessary, even longer — and be sure of success, than be 
on schedule with failure looming in the background. • 


Lessons 

• In dealing with potential problems, it is essential to get 
to the bottom of technical questions and understand 
why things work, not just why they don’t work. 

• It is important to hear, evaluate, and respect minoritv 
opinion, as well as to protect that minoritv’ from the 
conformance pressure of the majority. 


How can you foster a project environment in which people arc 
not afraid to speak up immediately when they notice that there 
is a problem ? 


I 0 ^ Recently retiring from his position as Deputy Center 

I fe a Doctor of NASA s Goddard Space Fligfit Center 

in Greenbeh, Maryland, BILL TOWNSEND is 
now the Vice President and General Manager 
of Civil Space Systems of Ball Aerospace and 
Technobgies Corporation . 

Former Goddard Center Director Al Diaz, speaking of his time 
working abngside Bill Townsend, says, “l wish everyone who is 
a cynic about what it takes to be successful in this business could 
read this story. Six and a half years ago when I first became Center 
Director, we had the only total failure of a mission in all my time 
at Goddard. Since then we delivered 40 spacecraft to orbit or 
systems to another user The deference between then and now is 
the wisdom that I had to bring Bill Townsend on board. Bill has 


In the end, we launched on July 15, 2004. We managed 
to work around each of these issues, mainly because we 
cracked them wide open each time. There’s a personal 


to the Goddar d Space Program. 


none. He has 
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FINDING OUR VVAv 

NASA's first Leadership Development Program (LDP) 
class was asked to define and complete a project that 
would have a significant impact on the agency. However, 
agreeing on a project took much more time than anv of 
us expected. Starting in the midst of the Integrated 
Financial Management rollout, One-NASA implemen- 
tation, and the Columbia Accident Investigation Board 
(CAIB) report release, provided a lot of potential topics 
to choose from. Brainstorming sessions led bv our 
leadership coaches yielded additional ideas. 

Projects were proposed to address workforce 
mobility, aging infrastructure, volunteerism, congres- 
sional communications, internal NASA communi- 
cations, new engineering management models, new 
NASA TV programming, virtual teaming, and cultural 
issues between the centers. We had one year to complete 
the assignment (while also completing two leadership 
development rotational work assignments, participating 
in six leadership trainings off site, attending briefings bv 
most of the agency leadership, and maintaining connec- 
tions with our home centers) and we were encouraged 
to tackle a Big Hairy Audacious Goal (BHAG). 

So how did a group of strangers come to a decision 
on our project, and what were the results? It's helpful 
to take a step back and look at how the first question 
was answered, as it is illustrative of several key findings 
from our project. 

THE MELTING POT 

At our first leadership training off site, which served 
as a get-acquainted meeting, the class of 20 revealed 
our backgrounds and passion for NASA to one 
another. We learned quickly that we were a group with 
diverse backgrounds, in every sense of the word. We 
represented nine of NASA’s 10 centers, and our work 
experience included scientists, research and facilities 
engineers, project managers, procurement specialists, 
lawvers, and senior managers. Our origins included 
small farms and big cities, numerous militarv and 
second-generation NASA families, and several who 
spent part or all of their childhood outside the U.S. 

A subsequent training session had the class 
complete the Myers-Briggs (MB) personality model. 
Of the 16 possible MB personality types, the class 
had members that fell into 12 categories. This further 
illustrated our diversity, but provoked a concern in 
some that the class may have difficulty working as a 
cohesive team. 


Several multi-hour discussions and much debate 
further revealed these personality differences. Team 
members that registered in the “traditionalist” category 
were poised and ready to hit the ground running 
on a project proposed by a NASA Senior Manager. 
Others that fell into the "visionary” category were 
deeply troubled about working on a project that did not 
personally resonate with them. Decision-making conflict 
also existed between those who preferred a “planned 
and organized” approach and those who preferred a 
“flexible and spontaneous” approach. Proposals were 
made to break the class into two teams, each with a 
different project, but these ideas were rejected in favor of 
focusing the energy of the entire team on one BHAG. 

CONSENSUS 

Gradually, one element, common to several of the 
proposed projects, became a unifying factor for 
the class. That element was collaboration, and more 
specifically, cross-center collaboration. The appeal 
for studying collaboration was based on its increasing 
criticality in support of the NASA mission, and its 
connection to increasing cooperation and breaking 
down cultural barriers between the centers. 

While the collaboration topic was related to other 
NASA studies (e.g. One-NASA, Diaz report) we discovered 
that no one had directly benchmarked collaborations 
within the agency by trying to uncover the elements of 
success and failure. Several adjustments to the emerging 
plan were made to satisfy everyone’s concerns, but we 
finally had consensus, the elusive win-win scenario that 
allowed everyone in the group to “buy-in.” 

Using the positive energy of the group as fuel, the 
project moved quickly into high gear. The class estab- 
lished a vision — achieving extraordinary mission success 
in the twenty-first century through powerful collabora- 
tions — and three top-level goals for the project: 

1) Catalog collaboration principles and best practices. 

2) Infuse collaboration best practices into new and 
existing tools and programs. 

3) Align incentives and structures to support effective 
collaboration. 

This vision was documented in a five-page plan 
that was used as our marching orders throughout this 
process. The team then established rotational leader- 
ship assignments for the overall project and each of 
the three goals, and established a set of operating 
principles that addressed teamwork, communication, 
and accountability 
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OFF TO THE RACES 

The first order of business was to establish those collab- 
oration best practices that were inherent in successful 
NASA programs and projects, and to identify those 
traits that led to inter-center conflict or otherwise 
inhibited progress. We decided to survey a number 
of NASA collaborations to assess their opinions and 
experiences on a number of characteristics that could 
influence their effectiveness. 

At the suggestion of Chris Williams, the 
LDP Program Director, we hired an independent 
Social Psychologist trained in the development, 
administration, and data analysis of unbiased surveys 
to help in the process. What a good idea that was! (I 
have to admit that I was hoping to dig through and 
analyze the survey data as I had done in years past as a 
flight test engineer at Dryden.) The consultant helped 
us adapt a list of potential collaboration drivers, brain- 
stormed by the class, into a two-part survey: a question- 
naire requiring a l-to-7 scale answer indicating the level 
of agreement to a particular statement, and an interview 
to be given by members of the class. The questionnaire 
allowed us to perform statistical analysis, and the inter- 
viewsprovidedopportunitiesfornewideasandunforeseen 
collaboration impediments to be raised. 

Following interview training by our consultant, 
the class was off to the races, canvassing the agency 
for the secrets behind good collaboration by interacting 
with projects with a budget of a few million dollars to 
massive billion-dollar programs. In each collabora- 
tion we targeted survey data collection from a project 
manager, a lead engineer/scientist, and a support worker 
on opposite sides of the collaboration. To ensure that 
we were getting candid responses, we established a 
process to assure people that their interviews would 
remain confidential. In less than two months, we inter- 
viewed Center Directors, Associate Administrators, and 
nearly 100 people from 16 different projects/programs 
across the agency, generating a mountain of data in 
the process. Additionally, a series of collaboration 
topics were evaluated by one of the Advanced Program 
Management classes. 


Although we spent several months selecting our 
project, the class was making significant progress 
toward our goals. Sub-teams were formed to concentrate 
on data analysis, training modules, integration of best 
practices into existing program management processes, 
systems mapping, and the latter used to identify the 
best leverage points for improving collaborations. The 
group had clearly developed a sense of trust and appre- 
ciation for each other's abilities over the time we spent 
together as a group. 

Over several weeks, the survey findings were boiled 
down to the most important elements. These findings 
were used as the basis for generating the collabora- 
tion best practices and a set of recommendations for 
improving the environment for collaborations within 
the agency. 

THE RESULTS 

The collaboration best practices (see sidebar, pg. 38) 
can be categorized into three areas: human element, 
project framework, and management involvement. The 
first area, human element, requires an investment 
in people, relationships, and communications. The 
importance of interpersonal communication cannot be 
overstated. The investment in travel to facilitate face-to- 
face communication is an investment in the success of 
the project. When asked what technology could improve 
collaborations, many respondents answered, “Star 
Trek transporters" or “faster aircraft" in order to get 
people face-to-face more often. The pivotal point was 
that it is not about the technology, but rather that 
establishing personal relationships is critical to establish 
trust and a willingness to share knowledge — which 
in turn overcomes rivalries and differences in cultures 
and processes. 

The second area, project framework, calls for 
an up-front investment in establishing common and 
agreed-upon goals, processes, roles and responsibilities, 
funding mechanisms, and establishing buy-in from all 
parties — before the project begins. Whether or not 
roles and responsibilities are clearly defined was found 
to have a strong impact on the success of collaboration. 
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A lack of clarity in roles and responsibilities most often 
resulted in an inefficient use of resources, wasted time 
and energy, frustration, distrust, and lowered morale. 
In our own collaborative effort, we found our five-page 
mission statement to be our bible. Without it, progress 
could not be tracked. 

Cultural differences between centers, when not 
presented as center rivalry, most often showed up 
as differences in processes. These differences led to 
frustration and confusion, and in some cases, mistrust 
and an unwillingness to communicate. 'There is also a 
need for up-front planning to blend processes, rather 
than allowing one group's processes to dominate. All of 
these problems can be overcome by increased personal 
interaction. In this way, people can learn how other 
centers or organizations operate, and they learn to 
understand each other's cultures. 

The final area, management involvement, employs 
project leadership to set and model the policies and 
standards, and it employs center senior management 
to support, encourage, and occasionally intervene on 
behalf of the collaboration. Project management must 
encourage respect for the other partner's knowledge 
and capabilities. Allowing the development of an "'us" 
vs. "them" attitude is detrimental to collaboration. 
C letting the teams face to face is once again an effective 
tool in this effort. 

One manager from the survey relayed a story about a 
long-running technical disagreement between centers 
that persisted for months. Finally the teams were 
brought together, closed into a conference room, 
and told to solve the problem. They did, less than a 
half-hour later. We also found that true in our own 
working group; we would banter thoughts through 
emails for several weeks, but resolve issues in hours 
during our face-to-face meetings throughout the year. 
The survey also indicated that difficult personalities can 
be highly disruptive to collaborations, especially when ego- 
related, Project managers must ensure that these people 
are not in positions that will lead to frequent conflict with 


thi‘ collaboration partners. Fstablishing points of contact 
between the partners to facilitate communication and 
serve as problem solvers was mentioned as an effective 
means for maintaining healthy collaborations. 

Senior managers' active involvement was found to 
be key and many were commended in the survey for 
providing periodic reviews, helping solve funding issues, 
and avoiding micromanagement. Survey respondents 
desired a more active role of senior managers in the 
development of collaboration agreements, setting of 
project expectations, and management of inter center 
conflicts. Additionally, there was a strong desire for 
senior managers to make personal visits to the collabo 
ration staff and facilities a clear show of support. 

There does not seem to be a widespread use of 
metrics for management to measure the progress or 
success of collaborative efforts. The most common 
measures of project success, often reviewed monthly 
by center management councils, arc schedule, budget, 
and technical progress. Managers rarely focus on the 
working relationships and processes, even though it's 
the team that drives success or failure. We recommend 
that metrics be developed to assess the health of 
collaborations. “These met rics should be reported as part 
of periodic project reviews so that issues get addressed 
in a timely fashion and not be allowed to fester 

From the very beginning, the class recognized that 
reports on a shell accomplish nothing. In order to 
make a real impact on the agency, the collaboration best 
practices had to be integrated into NASA systems. With 
that in mind, a multi prong approach was initiated. 

( Connections were established with the NASA Academy 
of Program and Project Leadership (APPL) and, at 
their suggestion, training materials were generated 
to support existing leadership training courses. The 
Chief Kngineer's Office supported an effort to integrate 
collaboration elements into the updated NASA Program 
Management Requirements and I landbooks. 

The groundwork is also being set for a process 
to assess ongoing collaborations and make the 
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How does your project rate? 


ip 5 '' 


recommendations necessary for them to achieve the 
highest standards. A class member also participated in 
the addition of “teamwork" as a new performance plan 
element for leadership positions. In order to illustrate 
the value of collaborations to the agency's mission, 
a new NASA Peer Award is also being established. 
A forum on collaboration also ran on NASA TV. Lastly, 
the LDP class is fanning out to brief all NASA centers 
at senior leadership meetings and town hall meetings 
on the best practices for successful collaborations. 


Partnership agreements must have clearly defined 


Managers & Leaders should 




Senior Managers should 



FOLLOWING OUR OWN ADVICE 

Without knowing it a-priori, our LDP class followed 
many of the important collaboration practices in 
the conduct of our study. First we spent time 
getting to know each other, our backgrounds and 
personalities. Second we worked, with some conflict, 
until we achieved buy-in on a common vision and 
goals. Next we defined roles and responsibilities and 
a set of operating principles that, in retrospect, the 
team closely followed. Throughout the process, our 
commitment to achieving the project goals for the 
betterment of the agency took priority over any parochial 
concerns or personal agendas. 

It is our hope and our vision that greater attention 
will be given to the nurturing of our collaborations 
across the agency. Highly effective collaborations are 
a key building block to fully achieving the vision 
of One-NASA and ultimately succeeding in our 
important mission. • 


BRENT COBLEIGH recently returned 
to Project Management at the 
k Dryden Flight Research Center after 

spending one year working on the Vehicle Systems 
and Centennial Challenges Programs at NASA 
Headquarters as part of the Leadership Development 
Program. Brent has 15 years experience working on 
atmospheric flight research projects including X-29, 
X-31, F-16XL Supersonic Laminar Flow. X-33, SR-71 
LASRE, Autonomous Formation Flight, and X-37. Prior 
to coming to Dryden, he received his Masters Degree in 
Aeronautical Engineering from the George Washington 
University/NASA Langley Research Center’s Joint 
Institute for the Advancement of Flight Science. 
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a tank. The non-commissioned officer in charge of the 

unit saw the tank once it was in plain view and sent I 


In order to perform research on decision making 
in field settings, Dr. Klein and his colleagues have 
developed new methods of Cognitive Task Analysis. 
Klein Associates has used Cognitive Task Analysis 
methods to study decision making in more than 60 
domains, including firefighting, command and control, 
software troubleshooting, healthcare, and consumer 
purchasing. Dr. Klein has presented workshops on 
Cognitive Task Analysis to more than 300 professionals 
in the U.S. and abroad, and has presented seminars on 
naturalistic decision making to a wide variety of groups 
such as the Smithsonian Associates program. 

As a researcher and storyteller f you preach about the 
power of stories as learning tools. How can project 
managers harness this power in their work every day? 
To start, we need to stress the importance of intuition — 
following your hunch, trusting your years of experi- 
ence to lead you in the right direction. Intuition, 
in and of itself, is extremely undervalued. Why? 
Because it's fallible. It's only a first step; it needs to be 
checked by analysis. But we have lots of tools and 
mechanisms for strengthening our analytical capaci- 
ties, and we don't have a similar repertoire for strength- 
ening our intuitions. 

How then , do we use stories to strengthen and apply our 
intuitions? 

We use stories when we make recognitional decisions. 
Most of our decisions are based on recognition. We 
use stories to map situations and say, "I've seen that 
before." In this way, I can call up incidents that I've seen 
myself, or that other people have told me they've seen. 
Then I can use the stories to evaluate my intuition. We 
also use stories to make sense of events. We start with 
basic scripts, we build onto them with the knowledge 
we've collected, and we turn them into stories. 


back to headquarters the message, "I see a tank," along 
with the grid coordinates. 

My friend was thinking, "Anybody could see the 
tank by now, because it was out in the open." So he 
watched it closely as it came down the valley, and then 
took a defensive position. He said to himself, "There 
is never just one tank. Nobody ever goes out all by 
himself. There has got to be at least one more tank." 

He kept watching, but he didn't seeing another tank 
come down the valley. So he realized that the second 
tank must already be in position. He started looking 
in the shadows to see where the other tank would be 
positioned to support the first one, and he found it. 
He said to himself, "Tanks usually travel in platoons of 
four. If there are two tanks, maybe there is another one 
or two." He looked deeper into the shadows and found 
the other two. 

Then he thought, "These guys are just sitting 
there, and the position they've taken up is a defensive 
position. So, what are they defending? " He decided that 
there might be a command post, and he looked in the 
likely places for a command post. Then it got a little 
windy, and he noticed the glint o fan antenna. Instantly, 
he found the command post. 

It was interesting to compare what my friend could 
see versus the non-commissioned officer, because the 
NCO was only reporting the tanks when they came 
into plain view. My friend wasn't just reporting what 
he was seeing. He was going beyond. He was looking 
for things. 

He was building a story based on his prior experiences. 
Exactly. He was looking for things, because he had a 
storytelling technique that told him what to look for. 
That's how this story-building activity helped him 
to make sense and to build a better account of this 


Can you give an example? 

Sure, I have an example in the form of a story: 

A friend of mine was a highly experienced Colonel 
in the Marines. He was part of an exercise at Camp 
Pendleton called "Hunter-Warrior." Marines — noncom- 
missioned officers — would go out in the field as forward 
observers to look for enemy tanks and equipment. They 
would radio back what they saw so that those tanks and 
other targets could be attacked. 

My friend wasn't part of the exercise, but he got 
permission to go along. At one point, the unit spotted 
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situation. Stories can help sharpen our intuitions by 
helping us with sense making, with anticipating a 
result, and with decision making. 

Are there key questions that we ask ourselves when we 
create these stories? 

Sure, for example, "What's the logic of this story?" Or, 
"How does this story work?" This is an important question, 
because a story works in a couple of different ways. 

One, it works sort of like an efficient experiment. 
When we conduct a standard experiment, we typically 


manipulate one variable. That’s the independent 
variable, and we measure changes in the dependent 
variable. Our research tends to only look at one or two 
variables at a time, which is unfortunate, because it is 
like looking at the world through a soda straw. We can’t 
see all of the variables and how they are interacting. 

When we build a story, we take into account 
several independent variables at a time. A story shows 
all of those variables as they interact. What we lose is 
the ability to control the independent variables, because 
we can’t set up the values. But what we gain is the sense 
of how these are interacting and working together. 
That’s a source of hypotheses. 

So a story is a basis for discovery? 

It’s a natural experiment that we use to our advantage; 
then w 7 e compile these experiments, accumulate them, 
and try to learn from them. That’s just one of three 
aspects of the logic of stories. 

And the second aspect? 

The second aspect has to do with mental simulations. 
During a mental simulation, you are constructing a 
story in your head. You say to yourself, "I know 7 how 7 
this starts. Let me work out the continuation.” Or you 
also might say, "I know 7 how this ends. Let me work 
out the beginning.” Or there also might be a situation 
where you say, “I know both how it starts and how it 
ends. Let me w 7 ork out the middle.” 

Canyon give an example of a mental simulation? 

Sure, and I can use one based on a story from ASK. 
You remember there w T as a story 7 in ASK 13 by Tom 
Riveliini? He talked about the airbags on Pathfinder. 
We got to see that great picture of the Mars landscape, 
the equipment looking great, a picture of him looking at 
the airbags, and we heard how everyone did their jobs. 

We all know that it worked. But he said, "It 
w r asn’t that simple. It wasn’t trivial to get those airbags 
configured so that they w 7 ould do their job. Here is w 7 hat 
really happened. . .” 

We’re suckers for stories like that because, w 7 e want 
to know 7 the inside part of w 7 hat happened. He led us 
through it, including the emotional ups and dow r ns. 
We heard how 7 he became discouraged as attempt after 
attempt failed. The story 7 got us to the point w 7 here w r e 
asked, "How did he ever get it to work?” He started w 7 ith 
a story that we all knew the ending to, but he said the 
interesting part is how w 7 e got there. 


Then what is ihe third aspect to the logic of stories? 
This aspect deals with how you make sense of a situation 
by combining its components. You’re compiling the 
data, the events, and w 7 hat you observed into some sort 
of frame that holds it all together. 

For example, the frame can be a map made up of the 
details of various places that shows how they connect. 
Or it could be something like a script that shows all the 
people involved in something and the part they play. Or 
it could be an outline of a routine of some sort. 

Which comes first, the data or the frame? 

That's an interesting question, because the fact is 
that neither of them comes first. You need the data 
to tell you winch frame is appropriate, but you need 
the frame to tell you what counts as data and which 
data to use. You create the framework and compile the 
data simultaneously. 

The story becomes a blend of the data and the 
frame. As you w 7 ork through the story, the frame 
gets richer and richer, because you’re deepening the 
account. A story allows you to do both simultaneously: 
Make the frame richer and identify new types of data. 

It sounds like an extremely effective way of evaluating 
and acquiring new information. 

It is. The problem is that w 7 hile stories are often 
important, they’re not sufficient. When I fly in an 
airplane, I don’t w r ant my pilots’ training to have been 
only hearing stories about how 7 to take off and land. 

I want them to have checklists. I want them to 
follow 7 procedures, because I know 7 that people forget 
things. But I don’t w 7 ant them to just know procedures, 
which are designed for situations that continuously 
repeat themselves, because sometimes the procedures 
don’t work for unique situations. 

So, you need the procedures, but a story might help you 
know how to handle a situation that they don't cover? 
And presumably as the world becomes more dynamic, 
these situations become more prevalent? 

Right. However, some organizations don’t want to 
buy into that. They think that they can come up with 
procedures so exhaustive that there is never a need to 
go beyond them. 

Researchers who have looked at this have never 
found that procedures alone are very successful. Yet, it 
is often an organizational quest to write them so they 
are. I can give you an example of an incident where 
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the organization refused to believe in the power of 
stories. I got this from Kim Vicente, a researcher at the 
University of Toronto. 

There was a crack nuclear power plant in Canada 
where the controllers were really, really good. All 
nuclear power plants are regularly inspected and tested. 
A day came for one of the periodic tests for this control 
room team. 

These guys had always scored really high in the 
past, but they had one flaw: They didn't always follow 
the procedures. For this, they were always reprimanded. 
They knew what they were doing, and they knew when 
they could do shortcuts, but they were tired of getting 
dinged for not following all of the procedures. Before 
the next test, they all banded together and made a pact. 
They said, "Whatever comes, hell or high water, we are 
going to follow the procedures." 

So the test comes, and they're given a tough 
situation. They're working on it, and they get into a 
loop. They take action-A, which produces situation-B. 
They respond to situation-B, which gets them to C. 
They follow the procedures, and the procedures get 
them right back where they started at situation-A. They 
just look at each other like, "This is amazing!" They 
follow the procedural loop around again and again, 
and each time they end up right back at the beginning. 
They are just loving the heck out of this — having a 
great time. 

The controllers finally stop them. In the end, the 
inspectors were so irritated that they wrote them up 
anyway, this time for "malicious procedural compliance." 

It's a funny story, but it shows that there are times 
to follow procedures and times not to, times to codify 
information and times when you need the context that 
goes beyond codification. 

So stories help with the practical knowledge that goes 
beyond the checklists. What is another storytelling tool 
that can be used in a dynamic workplace? 

Another tool is having people swap their stories in 
Lessons Learned sessions. The idea is that your peers can 
teach you valuable information, and you can teach them. 
Let me tell you another story that shows what I mean: 
We put on a workshop for fire fighters in 
Los Angeles. We were talking to battalion commanders 
and captains about how they could improve decision- 
making through the use of stories. 

I started by saying, "The purpose of this workshop 
is to improve decision-making skills." One of the fire 


fighters, a captain, asked, "But will it help with things 
like morale?" I answered that, "No, I don't see it 
helping with morale." 

I came back a couple of weeks later when we had 
our next session. The same fire fighter said, "Hey, you 
were wrong about stories not helping morale." He told 
us the story of how he came to this conclusion. 

Apparently, there was somebody in his company 
who was a real loser. This guy was always messing up, 
and they were constantly at each other's throats. After 
we finished the last workshop, the captain went back to 
his company. A few days later, the company responded 
to a fire call. This same guy in the company, again, does 
something really stupid. (The routine at this point was 
that the guy did something stupid, the captain goes 
over to him after the incident and yells at him. He asks 
him, "How many times have I told you not to do that?" 
And then he writes him up.) 

But this time, the captain had just come out of the 
workshop. Instead of yelling at the guy, he said "When 
you handled things that way, I was kind of surprised. 
Can you explain your reasoning to me so that I can 
understand what you were you trying to do? What 
was in your mind? Give me your story." The firefighter 
explained what he was trying to do and why, and the 
captain was amazed because it made sense. Then they 
were able to have a dialogue about how he'd handle 
other situations, and it was the first time they'd ever had 
a real discussion. 

The captain came back to our workshop and said, 
"I used to think this guy had an attitude problem. Now 
I realize that I was the attitude problem. When I let him 
tell his story before chewing him out, it changed the 
whole dynamic." 

That's part of the power of stories — changing the 
dynamic of situations with knowledge and understanding. 

That is what ASK Magazine is attempting to do for the 
field of project management. 

There are some great stories in the magazine. Somehow 
you've been able to create a culture that not only 
collects stories, but you're also sensitizing people to 
those stories so that they are even experiencing their 
world slightly differently. That's what you want when 
people come out of a storytelling workshop, or when 
they finish reading the magazine. You are sensitizing 
people to the value of stories, because they are an 
effective vehicle for knowledge. You are helping to build 
the culture of storytelling that we are both a part of. • 
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from the editor-in-chief Dr. Alexander Laufer 


A Tale of Two Houses: 

Building on a Foundation of Trust or Mistrust 

Trust has been a main theme in over 20 articles that have 
been printed in ASK so far 


These stories make it very clear: trust among project parties is not just an 

attitude that is nice to have. It is a must, since lack of trust costs money — often 
a lot of money. Trust helps resolve conflicts before they arise; trusting relation- 
ships are conducive to full and open exchange of information within the team; 
elaborate surveillance and control systems must be implemented to compensate 
for lack of trust, often with only partial effectiveness. In past issues, we've taken 


a look at projects that succeed because 
focused on how trust and mistrust are 
prejudice shapes what we see and how w< 

Reflecting on this, I remembered a story about my 
friend, T. Rust W orthy, who was in the market to buv a 
townhouse. His father was an experienced contractor, 
so after receiving a list of references from him, T. Rust 
pinpointed one on the list. He selected a developer and 
quickly struck a deal on a house that was in the process 
of being built. 

T. Rust then met with the architect, who was a 
consultant, to request design changes. He found out 
that changes went through a lengthv process: his 
requests were drawn up by the architect, an estimate 
of the cost was drawn up. approval was obtained by 
the chief engineer, and then the approved changes 
were sent to the site superintendent. This process 
took forever and was compounded by the fact that the 
architect hadn't been informed about the developers 
changes to the original design. 

He asked the developer if he could work directly 
with the chief engineer and site superintendent since his 


f these factors, but we haven't directly 
built. In this article we will see how 
! act. 

changes were small and didn't require major redesign. 
The developer told him that he used to do things that 
way when his business was smaller, but he had adopted 
a more formal process to eliminate misunderstandings 
and disagreements with his customers. Since he knew 
T. Rust’s father, however, he said he would work with 
him that way. During the completion of the house, two 
major episodes helped to establish a relationship of 
trust between the developer and T. Rust. 

First, the storage room that he had been promised — 
which was located in a separate storage building — was 
mistakenly sold to another customer by the sales agent. 
T. Rust simply accepted another room without making 
a fuss. Then the site superintendent made a mistake 
while securing the water pipes during a routine leakage 
test, resulting in water damage to the interior walls. 
Once T. Rust had been assured by his father that there 
would be no permanent damage, he didn’t make a big 
deal out that problem either. 
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The site superintendent was very grateful to T. Rust. 
Therefore, when it was his turn to make mistakes 
or change his mind, T. Rust was able to deal directly 
with the superintendent in an informal, friendly way. 
However, he made sure that the formal paperwork 
was always completed by the developer's main office. 
As time went on, he developed a trusting relationship 
with the chief engineer as well. This made the formal 
approval process faster and smoother. 

In contrast, my friend's future neighbor, one Miss 
Trust, was going through the same process to buy her 
townhouse. She, however, was having a less satisfying 
experience. Miss Trust and the developer initially got 
off to a bad start, because she had always thought badly 
of developers. She wouldn't do anything without the 
presence of her lawyer. The lengthy process for design 
changes only made her more positive that the devel- 
opers were underhanded. 

Since Miss Trust didn't trust the contractor, 
she went to the site every day to scour for mistakes. 
(In contrast, T. Rust stopped by only once a week 
and communicated mostly by phone.) When Miss 
Trust found discrepancies between the construction 
and design, she got angry and assumed that she was 
being cheated. 

She found out that T. Rust had been charged 
slightly less for a similar design change and refused to 
believe it was a result of the waived architect fee. On 
another occasion, T. Rust paid less than Miss Trust had 
for a similar scope of work. This was because T. Rust 
elected to have the work charged "cost-plus," allowing 
it to be finished as quickly as possible. Miss Trust on 
the other hand, didn't trust the contractor at all, and 
would never have approved a change without knowing 
the final cost. She signed a lump sum agreement which 
eventually turned out to be more expensive. 

In the end, T. Rust was satisfied and recommended 
the developer to others. Miss Trust served the same 
developer with a lawsuit. 

This story clearly shows that once we accept 
stereotypes, prejudice shapes what we see and how 
we act. Since initial opinions of team members are 
crucial, if possible, you should avoid recruiting team 
members who start the project distrusting you. You 
should build trust incrementally by making state- 
ments of intent that express the desire to trust the 
other party, followed by actions that support and 
comply with these statements. • 
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Speed Merchants: A Conversation with W. Scott 
Cameron and Terry Little 

ASK 12 

Grins and Giggles: The Launch Pad to High Performance, 
by Maj. Norman H. Patnode 

Earthly Considerations on Mars, by Tim Flores 
Trusting the Enemy, by Terri Rogers 
Get into Bed, by Jon Bauschlicher 

ASK 16 

The Eye Cannot See Itself, by Dr. Alexander Laufer 

ASK 17 

Passing the Baton: Lessons in Regret, by Terry Little 
Right on Time, Radically, by Ken Lehtonen 
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